Re: Proper Leveling Techniques - Rescheduling to start later

From: Steve House [MVP] (sjhouse.remove.this_at_to.send.hotmail.com)
Date: 12/31/04


Date: Fri, 31 Dec 2004 09:59:14 -0500

There is no such tool as "Change Actual Start Date." If there's an actual
start, then by definition it should never change unless you've made a typo
and entered the wrong date when you put it in. If it's a real Actual Start
Date that is describing a historical event - Joe was supposed to fidget the
widget last Monday and that's when he did it - and the entry in the project
file should always reflect that reality. If no work has been done on task,
the there is not and should not be an Actual Start entry. I hope you're not
putting in fictitious Actual Start entries in order to kludge the schedule
into looking like what you think it ought to look like are you?

I need to verify here that you are aware that there are three sets of start
and finish fields - Start, Baseline Start, Actual Start, Finish, Baseline
Finish, and Actual Finish. Start and Finish are what your schedule calls
for - your plan. Baseline Start and Finish are your original starting plan
before work was done - what you thought you would be able to do. Actual
Start and Finish are what you really DID do. Once work begins, the planned
dates (Start and Finish fields) reflect what you've done - history - and
what you still plan to do - forecast. When you enter a date in the Start
field it does NOT establish an actual start - instead it establishes a
planned start with an SNET constraint. You only get an actual start when
you enter a date in the Actual Start field. The Start and Actual Start do
interact but only in one direction. If I type "30 Dec" in the Start field
it just goes that one place while setting a constraint. But if I enter "30
Dec" in the Actual Start field it ends up BOTH the Start and Actual Start
fields

It is NEVER appropriate to use leveling delays to bring forward work or
otherwise to force the tasks to end up on certain dates - leveling has
nothing to do with that. The only time leveling delays should be anything
except blank is when the resource leveling tool has introduced them to
resolve resource overallocations. Likewise, setting the default scheduling
option to "New Tasks Start on Current Date" doesn't have anything to do with
rescheduling existing tasks either. That setting is just what it says-
where should tasks being ADDED to the plan be placed? Surely you're not
deleting a delayed task and re-entering it as a new new task are you?

I don't know why you're so adament againt using SNET constraints in any
situation. I'm one here who criticizes what I consider to be the overuse of
constraints of all types all the time but that's only because people
frequently are trying to use them to force an arbitrary schedule onto their
plan and by so doing forcing an end run around Project's intended purpose.
But if there's a legitimate reason for them, by all means use them. If a
vendor won't deliver needed parts before 15 Jan, a SNET of 15 Jan on the
task that requires them makes perfect sense. Likewise, in the case of
moving a task that was supposed to be done last week but wasn't worked on
for some reason, moving the undone work forward to next week by letting the
Update Project tool apply an SNET constraint is perfectly ok - that's what
constraints are for. In general the purpose of a constraint is to control
the placement of tasks when something external to the project instead of the
task's logical predecessor relationships and the availability of resources
controls the task's dates. Since new tasks added now that the project is
underway can't be worked on in the past (assumption being that work on a
task never takes place before it is entered in the plan) even if they could
have been according to their predecessors, a SNET of the next work day on a
newly added task is perfectly appropriate. Work on planned tasks that
SHOULD have been done last week but wasn't, likewise, can only take place in
the future, thus a SNET of the first day work could now be done is also
perfectly in order.

You should never be "shuffling tasks" as you put it. Revising the schedule,
certainly. But the function of Project is not to illustrate a schedule you
have come up with by hand. It's job is to tell YOU the schedule you can
have that gives you the optimum project timeline and budget. You don't tell
it the schedule, it tells YOU the schedule.

-- 
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs
"BAndrews" <bandrews@trendinfluence.com> wrote in message 
news:OlvvSUz7EHA.1260@TK2MSFTNGP12.phx.gbl...
>I guess what I was looking for here is that it is OK to use
> Tools->Tracking->Update Project->Reschedule Unfinished work rather that
> Tools->Update Tasks->Change Actual Start Date.
>
> The reason i am trying to clarify is because the first option creates
> constraints "Do Not Start Until" whereas changing the Actual start date 
> does
> not add constraints.
>
> Really just trying to understand when its appropriate to allow a "Do Not
> Start Before" constraint to be added.... rather than working with some 
> other
> method such as leveling delays or actual start dates to shuffle these 
> tasks
> around. The concern being that i may actually want to use different
> constraints on these tasks and how would that affect me in the long run.
>
> So I will take this as: It's perfectly acceptable to use "do not start
> before" constraints to move tasks around? I guess this means setting the
> default Scheduling option to schedule new tasks "Start on Current Date"?
>
> I do understand btw what you are articulating below with respect to
> leveling...
>
>
> "Steve House [MVP]" <sjhouse.remove.this@to.send.hotmail.com> wrote in
> message news:OjyAw8n7EHA.2156@TK2MSFTNGP10.phx.gbl...
>> Actually what I've been saying is you SHOULD be using the Tools, 
>> Tracking,
>> Reschedule Uncompleted Work and NOT using Leveling to try to bring the
> tasks
>> to the current date or the future.  Leveling will never move tasks - 
>> past,
>> present, or future - unless a specific condition exists.  That is, the
>> resource doing that task is also booked on other, higher priority, tasks
>> that are scheduled at the same time so that the total work he must do in
>> that time frame exceeds the time allowed to do it.  If Joe is scheduled 
>> to
>> be on task A 100% for 8 hours on Monday and ALSO scheduled for task B 
>> 100%
>> for 8 hours on Monday, he's booked to be in two different places at once
> and
>> is expected to somehow magically produce 16 man-hours of work during a
>> single 8-hour time period, a physical impossibility.  Leveling will move
> one
>> of those tasks to Tuesday if he's free then.  That's all leveling ever
> does.
>>
>> Try this little experiment...
>>
>> 1:  Create a new project plan with a start date of 01 Dec.  Default
> standard
>> calendars and automatic leveling turned OFF.
>> 2:  Enter 6 tasks A (3d), B (4d), C (5d), D (6d), E (5d), F (4d), no
>> constraints on any of them.
>> 3:  Link those tasks A->B, B->D, A->C, C->D, D->E->F (note B and C are
> both
>> successors to A and predecessors to D so they go in parallel for a few
>> days).
>> 4:  Create resource Fred and assign him to all tasks 100%.  This results
> in
>> Fred being overallocated for the 4 days he's expected to work on both
> tasks
>> B and C.
>> 5:  Level resources.  Task B moves out to the following week because that
>> (instead of moving C) results in the least pushback of the finish date.
> All
>> the later tasks also move driven by their links.
>> 6:  Using the tracking toolbar for simplicity, show task A 100% complete
> and
>> task C 50% complete.
>> 7:  Use the Reschedule Uncompleted Work tool with work resuming after
>> tomorrow, 31 Dec 04.  The project was interupted and work resumes Monday
> 03
>> Jan 05.  All of task B and the unworked portion of C get pushed to next
> week
>> and the rest of the project gets pushed out to later in January.  B, D,
> and
>> E automatically get SNET constraints of 31 Dec 04 set by the reschedule
>> tool.
>> 8:  Fred is again overallocated because B and the unworked part of C are
>> once again happening at the same time.
>> 9:  Resource level once again.  C doesn't move and the unworked part of C
>> will be scheduled next Mon and Tue.  B *does* move and gets pushed to 
>> next
>> Wed, Thur, Fri, and Mon.  The rest of the task's D, E, and F also get
>> adjusted to a few days later in Jan because of their links.
>>
>> -- 
>> Steve House [MVP]
>> MS Project Trainer & Consultant
>> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>>
>>
>>
>> "BAndrews" <bandrews@trendinfluence.com> wrote in message
>> news:elkq8An7EHA.2124@TK2MSFTNGP15.phx.gbl...
>> > The nature of our business is as such that we have service based 
>> > project
>> > work, internal development that happens many times around the project
>> > work,
>> > internal project work (sales support, etc) as well as ongoing services
>> > that
>> > we are trying to fit into an overall management plan... and we are a
> small
>> > company.
>> >
>> > We may have to stop certain tasks to engage other tasks. While this may
>> > not
>> > sound like a perfect world scenario, it is reality in many situations.
> It
>> > is our goal to be able to show the impact of moving resources to other
>> > tasks
>> > and to have accurate revised schedules.
>> >
>> > So if a task has been "backburnered" say for 30 days (and no work has
>> > begun
>> > on these tasks), and there are gaps in the resources time for whatever
>> > reason - this will prevent leveling from helping to reschedule those 
>> > old
>> > tasks (or so it seems -- leveling will not bring unschduled tasks
>> > current).
>> > Should we use Tracking -> Update Tasks and change the actual start date
> to
>> > the current date to get these tasks back in the current leveling
> "playing
>> > field"? Is there ever a time that we should be using "Tracking -> 
>> > Update
>> > Project-> Reschedule Unfinished Work"?
>> >
>> > Thanks for the thoughts!
>> >
>> >
>> > "Steve House [MVP]" <sjhouse.remove.this@to.send.hotmail.com> wrote in
>> > message news:u6A9gKb7EHA.824@TK2MSFTNGP11.phx.gbl...
>> >> As for links being often misused, my opinion is yes.  All too often
> links
>> >> are used to force a specific timeframe onto the project.  That to my
> way
>> > of
>> >> thinking is putting the cart before the horse.  Links are basically to
> be
>> >> used to model the logic of the process the project uses to create the
>> >> deliverables.  Erecting the walls of a building is a predecessor to
>> > putting
>> >> on the roof because Nature and gravity doesn't give us the option of
>> >> building the roof in midair and then tucking the walls in under it
> later.
>> > A
>> >> link indicates a mandatory sequence, not simply a desired sequence. 
>> >> The
>> > the
>> >> timeframe is a product of the process model, not the other way around.
>> >>
>> >> Your "leveling dependencies" can be achieved indirectly throught the
> use
>> > of
>> >> task priorities.  Joe Resource is assigned to three tasks A, B, & C
> that
>> > can
>> >> be done in any order.  You'd like him to work on them in order of B, 
>> >> C,
>> > and
>> >> A.  So you assign B a high priority, C a mid-level priority, and A a
> low
>> >> priority.  When you level, if they are in conflict A will be the first
> to
>> >> get delayed, then C, with B staying put.
>> >>
>> >> Why do you need to make sure that the leveling order is not changed?
> In
>> >> many cases if delays etc require the plan be modified the leveling
> order
>> > for
>> >> non-dependent tasks SHOULD change!  When the sequence actually 
>> >> matters,
>> > use
>> >> predecessor links to model it. Remember that leveling ONLY has any
> effect
>> > at
>> >> all when one or more of a group of tasks has to be delayed because the
>> >> resources assigned to them are booked to do more work in a given time
>> >> than
>> >> they are actually able to do.  Joe was going to work on task A, B, & C
>> > (each
>> >> 3-day duration) whose order doesn't matter and we presently 
>> >> arbitrarily
>> > have
>> >> him doing them in that order in our project.  B is also a successor to
>> > task
>> >> X that is done by someone else that happens to be ending just about 
>> >> the
>> > time
>> >> A ends.  So Joe's tasks start out with the sequence ABC.  But X gets
>> > delayed
>> >> a couple of days so now B is pushed while A & C stay in place ending 
>> >> up
>> > with
>> >> B pushed to the same days as C, Joe now being double booked those days
>> >> and
>> >> left idle for the 3 days he originally was scheduled to work on B.
>> >> What's
>> >> wrong with you letting Joe know that now he should work on his tasks 
>> >> in
>> >> order of ACB, working on C while he's waiting for X to end to allow B
> to
>> > be
>> >> able to start?
>> >>
>> >> If you need to retain the original plan for comparison purposes, 
>> >> that's
>> > what
>> >> the Interim Plan slots are for, storing the task's original start and
>> > finish
>> >> so you can see what it was like before changes were introduced.  The
>> >> Leveling Gantt view shows preleveling and post leveling schedules as
>> >> well.
>> >>
>> >> I was using actuals in my example for completeness but the principle 
>> >> of
>> >> rescheduling the incomplete work applies whether or not the tasks in
>> >> question have actually started.  If it is a common occurance that 
>> >> tasks
>> >> aren't being worked according to plan you have an even bigger issue -
>> > you're
>> >> going to a lot of trouble and spending a lot of money developing a 
>> >> plan
>> > that
>> >> establishes when work must take place in order to meet the business
>> >> objectives that gave rise to the project.  You came up with a plan 
>> >> that
>> >> is
>> >> the optimal strategy to bring the project in on-time and in-budget.
> Your
>> >> project depends on the resources doing what they've been told to do in
>> >> the
>> >> sequence and in the time frame they been directed to work on it.  So
> why
>> >> aren't your resources doing what they've bloody well been told to do
> and
>> >> working the plan you published?  It's inevitable that it's going to
>> >> happen
>> >> every once in a while but if it's the norm something is seriously 
>> >> wrong
>> > with
>> >> your project communications and responsibility matrix.
>> >> -- 
>> >> Steve House [MVP]
>> >> MS Project Trainer & Consultant
>> >> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>> >>
>> >>
>> >>
>> >> "Bryan Andrews" <bandrews@trendinfluence.com> wrote in message
>> >> news:eRdPLvZ7EHA.2600@TK2MSFTNGP09.phx.gbl...
>> >> > Thanks Steve,
>> >> >
>> >> > What if those tasks have not even begun yet and have no actuals?
>> >> >
>> >> > I really wish there was a way to create "leveling dependencies". Do
> you
>> >> > think this would be possible with a "Project Addin"? :) I say this
>> > because
>> >> > it would really give some piece of mind when you are pushing
> schedules
>> >> > around. In the scenario you created, once i relevel - it is 
>> >> > extremely
>> > hard
>> >> > for me to track all of the changes and be sure that the leveling
> order
>> > has
>> >> > not changed... perhaps they have not, but when the project gets to
>> >> > about
>> >> > 1000 tasks it gets rather difficult.
>> >> >
>> >> > Seriously though i am starting to see that task dependencies are
>> > probably
>> >> > misused by many just for ease of use... does this sound accurate?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > "Steve House [MVP]" <sjhouse.remove.this@to.send.hotmail.com> wrote
> in
>> >> > message news:uLQgulS7EHA.824@TK2MSFTNGP11.phx.gbl...
>> >> >> You're on the right track with the Tools, Tracking, Reschedule
>> >> >> Uncompleted Work tool.  First enter in actual progress showing what
>> > work
>> >> >> was done when. For simplicity let's ignore that this is a holiday
>> > period.
>> >> >> Today is the 28th.   Let's say task Fidget which is expected to 
>> >> >> take
> 2
>> >> >> weeks was supposed to start last week on Monday the 20th.  Duration
> =
>> > 10
>> >> >> days, start 20 Dec, finish 31 Dec.  It actually started one day
> late,
>> > on
>> >> >> the 21st.  We worked on it all day the 21st, 22nd and 23rd and then
> it
>> >> >> got interrupted. We should have worked on the 24th, the 27th, and
>> >> >> today
>> >> >> but for some reason we didn't. So the first step is to post to the
>> >> >> schedule what we actually did.  Display the tracking table and 
>> >> >> enter
>> >> >> in
>> >> >> Actual Start of 21 Dec and Actual Duration of 3 days.  Note that 
>> >> >> you
>> > must
>> >> >> enter this into the "Actual Start" and "Actual Duration" fields, 
>> >> >> NOT
>> > the
>> >> >> plain "Start" and "Duration" fields in the Entry table.  Project 
>> >> >> now
>> >> >> calculate the task is 30% done (3 done/10 to do) and shows a new
>> > forecast
>> >> >> Finish date of 03 Jan, one work day later than originally planned
> due
>> > to
>> >> >> the one day late start.  BUT there's work we should have done in 
>> >> >> the
>> > past
>> >> >> that we didn't do.  We don't have a time machine that lets us go
> back
>> > to
>> >> >> do the work we missed so the only thing we can do with it is move 
>> >> >> it
>> >> >> to
>> >> >> the first time that we CAN get back to it, namely the first workday
> in
>> >> >> the future (assuming here we can get back to work on it then).  So
>> >> >> here
>> >> >> it is the evening of the 28th - we use the Tools, Tracking,
>> >> >> RescheduleUncompletedWork after 28 Dec tool to move the unworked
> part
>> > of
>> >> >> that task to begin anew tomorrow the 29th. Now it will show Start 
>> >> >> of
>> >> >> 21
>> >> >> Dec, Duration of 10 days, Actual Duration covering the 21st, 22nd,
> and
>> >> >> 23rd.  Then  there's a split with the dotted line covering the 
>> >> >> 24th,
>> >> >> 27th, and 28th.  The work resumes the 29th and the new Finish is 
>> >> >> now
>> >> >> projected to be at the end of 06 Jan.  Any tasks dependent on this
> one
>> >> >> will also be pushed out accordingly by their links. If resources
>> > working
>> >> >> on this task were already assigned elsewhere on the new dates this
> now
>> >> >> takes place, namely the 3rd, 4th, 5th, and 6th and those tasks were
>> >> >> not
>> >> >> linked to this one so they would already have been moved by their
>> > links,
>> >> >> thus creating overallocations on those days, you'll need to 
>> >> >> re-level
>> >> >> those resources accordingly.
>> >> >> -- 
>> >> >> Steve House [MVP]
>> >> >> MS Project Trainer & Consultant
>> >> >> Visit http://www.mvps.org/project/faqs.htm for the FAQs
>> >> >>
>> >> >>
>> >> >>
>> >> >> "BAndrews" <bandrews@trendinfluence.com> wrote in message
>> >> >> news:%23zdqZ2R7EHA.128@TK2MSFTNGP15.phx.gbl...
>> >> >>> OK, so following this thread and the assumptions that my
> organization
>> >> >>> would
>> >> >>> like to use project in "one of many proper methods" -- which is to
>> >> >>> use
>> >> >>> priorities and delays to properly schedule tasks... what is the
>> >> >>> proper
>> >> >>> way
>> >> >>> to push out tasks that did not begin on schedule?
>> >> >>>
>> >> >>> For example, i got my project plan created and levelled perfectly
>> >> >>> with
>> >> >>> the
>> >> >>> first task to start on 12/1 of this year. We pushed forward 
>> >> >>> through
>> >> >>> tasks
>> >> >>> until the 10th at which time the project was put on hold for
> another
>> >> >>> project
>> >> >>> (that was not in Project Server). A week later we come back and 
>> >> >>> try
>> >> >>> to
>> >> >>> pick
>> >> >>> up where we left off....
>> >> >>>
>> >> >>> What is the best way to move the tasks that have not been 
>> >> >>> completed
>> >> >>> to
>> >> >>> the
>> >> >>> current day and not change any of the leveling?
>> >> >>>
>> >> >>> I know you can use Tools->Tracking->Update Project to "reschedule
>> >> >>> uncompleted tasks to start after" but this seems to put "do not
> start
>> >> >>> until"
>> >> >>> constraints on the tasks. I can use Tools->Tracking->Update Tasks
> and
>> >> >>> update
>> >> >>> the actual start date, but this doesn't seem correct (after
> glancing
>> > at
>> >> >>> it).
>> >> >>>
>> >> >>> It really would be cool to have some sort of "leveling
> dependencies"
>> >> >>> that
>> >> >>> would allow you to keep the order of tasks in tact (and move them
>> >> >>> around)
>> >> >>> without misusing real dependencies.
>> >> >>>
>> >> >>> Thanks for any thoughts on strategies here.
>> >> >>>
>> >> >>>
>> >> >>> "Bryan Andrews" <bandrews@trendinfluence.com> wrote in message
>> >> >>> news:OD2eoQd4EHA.2016@TK2MSFTNGP15.phx.gbl...
>> >> >>>> To work from an earlier example:
>> >> >>>>
>> >> >>>> We have 10 illustrations to create and we have them broken out
>> >> >>>> into separate tasks. These should not be assigned finish to start
>> >> >>>> because
>> >> >>>> theoretically i can assign them to 10 different designers which
>> >> >>>> would
>> >> >>> allow
>> >> >>>> me to complete them in an hour -- and there is nothing about the
>> > first
>> >> >>>> illustration that must be completed before i can start the second
>> >> >>>> illustration.
>> >> >>>>
>> >> >>>> I happen to have 1 designer available so i will assign him to 
>> >> >>>> all.
>> >> >>>>
>> >> >>>> Since these are all set to start at the same time, the second i
>> > assign
>> >> >>>> the
>> >> >>>> second task (and third and forth, etc) the resource is
>> >> >>>> overallocated.
>> >> >>>> What
>> >> >>>> is the preferred leveling method for people. I understand that 
>> >> >>>> you
>> > can
>> >> >>> click
>> >> >>>> Level or have Automatic Leveling, but is this what most people
> use?
>> > Or
>> >> >>>> do
>> >> >>>> people jsut adjust schedules in resource usage as suggested
> earlier?
>> >> >>>>
>> >> >>>> If adjusting the schedule is one way, how do you effectively
> adjust
>> >> >>>> task
>> >> >>>> schedules for without creating constraints on the tasks? Which
> view
>> > is
>> >> >>>> actually used to effectively achieve this?
>> >> >>>>
>> >> >>>> If you are manually leveling, are you just adjusting delays? Is
>> >> >>>> there
>> > a
>> >> >>> more
>> >> >>>> intuitive or graphical way to do this? I would think there would
> be
>> > an
>> >> >>> easy
>> >> >>>> way to control priorities as well by dragging tasks around...
>> >> >>>>
>> >> >>>> Thanks for any thoughts.
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>>
>
> 


Relevant Pages

  • Re: Proper Leveling Techniques - Rescheduling to start later
    ... You don't tell it the schedule, ... >> It is NEVER appropriate to use leveling delays to bring forward work or>> otherwise to force the tasks to end up on certain dates - leveling has>> nothing to do with that. ... The only time leveling delays should be>> anything except blank is when the resource leveling tool has introduced>> them to resolve resource overallocations. ... >> I don't know why you're so adament againt using SNET constraints in any>> situation. ...
    (microsoft.public.project)
  • Re: Adding a predecessor does not change date?
    ... I think there's an even stronger case to be made for NOT using constraints such as you suggest in the Server world - as a PM you are intimately familiar with slack time - how to obtain a report on it and the report's interpretation - but the Executive and others viewing the plan probably lack such technical expertise. ... using slack works well if you know what you're looking at and don't overlook the fact that you MUST tweak the schedule in the planning phase until all the negative slacks go away. ... But it is far more obvious what is going on in the plan if one sees a nice big red diamond in the indicator column indicating a missed deadline, a date in the Finish column that shows where you really are going to end up if you keep on going on your present path unless you do something to fix it, a pretty green arrow on the Gantt chart itself showing what your requirements are, and task's end or a milestone diamond off to the the right of that arrow glowering at you demanding you figure out a valid way to move it to the left. ...
    (microsoft.public.project)
  • Re: How do I move an entire group of tasks
    ... and I need to move the start date earlier, I have to adjust each one ... With thousands of tasks and years on the schedule, ... set up the plan is to have a fully linked dynamic schedule. ... Avoid the use of constraints since they defeat the ability of Project to ...
    (microsoft.public.project)
  • Re: Leveling - Resources are not leveled
    ... according to the current plan. ... > The only purpose of showing these very tough constraints at a date they ... The information saying that the schedule is impossible is there ... >> are not MSO in terms of the way they are entered into Project. ...
    (microsoft.public.project)
  • Re: Leveling - Resources are not leveled
    ... The only purpose of showing these very tough constraints at a date they will ... The information saying that the schedule is impossible is there ... > are not MSO in terms of the way they are entered into Project. ... > building the plan is to help you make such scheduling decisions. ...
    (microsoft.public.project)