Thanks Steve. You and Dale both gave really thoughtful (and
time-consuming,
I am sure, ) answers. I am carefully studying both of your responses and
will be showing them to my boss shortly. I'll let you know how it all
turns
out.
In the meantime, I welcome more opinions. The more upfront and honest
(even
if hard-edged) the better.
Thanks all.
:
I'm not sure on the task splitting you're getting because I don't have
specific information to work with but some general considerations.
No offense intended but IMO you DON'T know what the timeline is. What
you
know is what you HOPE the timeline might be, wishful thinking without
basis
in fact. If Project is telling you something different from what you
expect, Project's version is more likely to be a valid predictor of
what's
going to happen when you go out and try to have resources actually do
the
work.
The fundamental problem seems to be that your boss wants to tell
Project
what the timeline will be. That's getting it backwards, IMHO.
Project's
fundamental job is to tell HIM what timeline he can reasonably expect
to
achieve given what needs to be done, the amount of work each part of it
will
take, and the assets he has at his disposal to do it. He doesn't tell
Project the timeline; Project tells HIM the timeline that will result
from
what he has input as the tasks and resources. If its results don't make
him
happy, he can't just kludge it to make it look better by,say, turning
off
recalculation, he actually has to change the input - change the project
scope, obtain more resources, find ways to work more efficiently, look
for
sequenced tasks that could be done in parallel, etc. If he chooses not
to
pay attention, he's trying to force a square peg down a round hole and
it's
very likely the project will fail.
W=D*E is not an approximation or a watered-down generality, that is
exactly
how Project calculates in every single instance. No exceptions. The
task
type influences it in the sense that any linear equation has an
independent
variable, a dependent variable, and a constant. We have a task
estimated at
5 day and assign someone to it who works 8 hours per day giving 100% of
their attention to it. That means the work required to create that
task's
deliverable is 40 man-hours. Now I'm going to change something. What
factors in my equation are the variables and what factor is the
constant?
If it's constant work, I can change the duration and have project
calculate
the percentage or change the percentage and have project recalculate
the
duration. In most cases I think that is the appropriate setting because
work
usually takes what it's going to take and there's not a lot of control
you
have over it. If it usually takes me a month to write a program
module
it's not likely I can do one in 2 weeks just because someone says I
have to,
at least not and maintain quality. Or I can choose to hold the
duration
constant or hold the percentage constant. What determines the setting?
My
understanding of the nature of the work and the resources assigned to
it.
If your boss has set up a timeline and it gets scrambled when you
assign
resources, that is telling you something valuable. What it is telling
you
is that when you have your resources work according to the way you want
to
assign them, that timeline is unrealistic. Project is telling him what
he
will GET, not just parroting what he wants. If what it calculates
after
assigning resources is not what he wants the project to be and the
model is
otherwise valid with regard to links etc, he has to do one of two
things -
either change his expectations or re-think the resource assignments.
(You
might show him this message so he doesn't blame you for the bad news
<grin>.) If he is unwilling to do either, IT IS VERY LIKELY THE
PROJECT
WILL FAIL!!!! The reason Project does what it does is to alert you to
that
fact early enough to have a chance of doing something to prevent it.
Work can only takes place when resources are there, available to work,
and
not otherwise committed to other conflicting tasks. That seems obvious
but
it is a point often overlooked by eager bosses. If Bill is scheduled
to be
on holiday Monday and he is assigned to a task currently scheduled for
Monday, the task must move to Tuesday so its schedule changes to
conform to
when he is going to be there. Non-working time is not scheduled around
the
task requirements unless you do it manually, editing the resource
calendar
to move nonworking time that is causing tasks to shift unacceptably to
days
that work better for you; tasks are scheduled around resource
non-working
time as defined by the calendar. Secondly, resources cannot be in 2
places
at once. If I have task A on Monday and also task B and I assign Bill
to
both of them and expect him to devote 100% attention to each, he simply
cannot do it. The assignment percentage defines how much work out we
get
for each hour of time put in and while we might get less than the
maximum we
can never get more. In one hour of duration it is physically
impossible for
one person to generate more than one man-hour's worth of work output.
If
the person is scheduled for 100% on Task A for Monday and also
scheduled
100% for Task B, also on Monday, it is impossible for that to be worked
as
planned. You might publish such a schedule but when the time comes to
do
the work, he WILL be late for one or both of the tasks, guaranteed!
That's
what Project is trying to tell your boss only he doesn't seem to want
to
hear it. So how does Project resolve the situation? It moves one of
those
tasks to Tuesday (assuming the resource is free) when you trigger
leveling.
Your original schedule asked for 16 man-hours of work from one person
during
an 8 hour duration, an impossibility - the new one calls for 16
man-hours of
work to be produced during a 16 hour duration period, something that
*is*
possible for one person to do. Another option is to edit the resource
assignment level so he's working 50% on each task, thus extending the
ending
of both of them from Monday to the end of the day Tuesday, again
resulting
in 16 total man-hours of work being done in a 16 hour time period. A
third
option is to take the guy off of one of the tasks and find someone else
who
is presently idle to pick it up. Or finally just not do one of the
tasks
altogether, drop it completely from the plan, if you can get away with
it.
Anything else, the project will fall behind no matter what your
timeline
says.
You *can* be in complete control of the timeline but you can't just
arbitrarily pull time frames out of thin air and expect them to happen.
As
I've said in other posts, the command "Number One, make it so!" only
works
in the Star Trek movies. For the real world those timelines are driven
by
physical processes, not executive fiat, and to control the timeframe
you
must manipulate the factors behind it that actually affect it. If I
have to
assemble 100 widgets, one person can do a maximum of 10 a day, I only
have
one assembler on the payroll, and my budget won't allow overtime, it
will
take at least 10 days no matter whether you like it or not. If I need
it in
5 to meet a contract deadline, my only options are to get a second
assembler
somewhere or spend the money for overtime. Just plucking a mandate out
of
thin air and declaring that I'll have the guy do 20 a day just simply
won't
work.
Hope this helps ...
--
Steve House [MVP]
MS Project Trainer/Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
an addendum to my initial post....
my boss wants to be able to show that recources are assigned to
tasks, but
have us be in complete control of the overall timeline.
He is frustrated because he can set up an initial timeline and get
really
neat looking reports, but that once we "throw resources at it" MSP,
OR
make
any changes at all to anything after that initial set up, MSP behaves
unpredictable and messes up our timeline. He is confident in the
software
only from the DAY 1 set up.
ynamic Scheduling with Microsoft